home *** CD-ROM | disk | FTP | other *** search
/ Chip 1996 April / CHIP 1996 aprilis (CD06).zip / CHIP_CD06.ISO / hypertxt.arj / 9537 / SWFEJL.CD < prev    next >
Text File  |  1996-02-19  |  13KB  |  191 lines
  1.           @VA szoftverfejlesztés válsága és fejlôdése@N
  2.  
  3.               A    legtöbb    program    mindmáig   néhány    formális
  4.           programnyelv     alkalmazásával,     kézmûipari,    intuitív
  5.           módszerekkel   készül.   Napjainkban   azonban   egyre  több
  6.           fejlesztô  kezdi  munkáját   a  feladat  elemzésével,   majd
  7.           folytatja szisztematikus megoldásával.
  8.               A  hagyományos  programozási gyakorlat  alig  tud lépést
  9.           tartani a mind gyorsabb, mind olcsóbb és mind kisebb hardver
  10.           igényeivel.   A   hálózatba   kapcsolás   esetenként   újabb
  11.           bizonytalansági  tényezôket  visz   a  rendszerbe.  A   nagy
  12.           hálózatokban ugyanis számos olyan hiba jelentkezik, amit  az
  13.           egyedi berendezéseken nem  lehetett észlelni. A  komplexitás
  14.           növekedésével mind  gyakrabban fordulnak  elô zavarok.  Ha a
  15.           rendszer mérete akkorára nô, hogy jól képzett szakember  azt
  16.           nem  tudja  teljes  egészében  áttekinteni,  a   hagyományos
  17.           fejlesztési módszerek általában csôdöt mondanak.
  18.               Szakértôk szerint az eddig elkészült nagy rendszerek  55
  19.           százaléka  a  tervezettnél  többe  került,  68  százalék nem
  20.           készült  el  a  tervezett  határidôre,  88  százalékuk   nem
  21.           teljesítette az elvártakat, ezért át kellett írni azokat.  A
  22.           jelentés  azonban  nem  szól  a  megbízhatóságról. Åltalános
  23.           vélemény  szerint  a  nagy  rendszerek  viszonylag   gyakran
  24.           omlanak  össze  valamely  váratlan  esemény  vagy  körülmény
  25.           miatt, jelentôs veszteségeket okozva.
  26.               Négy éve a Software Engineering Institute felállította a
  27.           képesség érettségi modelljét, a Capability Maturity  Modelt,
  28.           CMM-et,  amivel  öt  osztályba  sorolhatók  a  programok. Az
  29.           elsôbe a  kaotikus jellegû,  az ötödik  osztályba a teljesen
  30.           logikai  felépítésû   programok  sorolandók.   Ezt  követôen
  31.           megkezdôdött  a   kiválasztott  szoftverek   minôsítése.  Az
  32.           eredmény lehangoló: a  jelenleg futó programok  75 százaléka
  33.           csak  az  elsô  osztályba  sorolható,  mert  nem ismeretesek
  34.           alkalmazásuk határai, nem tudni, mikor vétenek hibát és azok
  35.           milyen következményekkel járnak; 24 százalék üti meg a 2--3.
  36.           osztályba  sorolás   mértékét,  és   csak  egy-két   program
  37.           érdemelte ki az 5. osztályú minôsítést.
  38.               Egyre  többet fordítanak  mind a  nagy, mind  a  polcról
  39.           levehetô  szoftverek  minôség-ellenôrzésére.  A  korlátozott
  40.           fejlesztési idô és  költségkeret miatt a  fejlesztôk mindkét
  41.           kategóriában  gyakran  vétenek. A  hibák  esetenként sohasem
  42.           kerülnek  felszínre, a  tömegesen alkalmazott  szoftverekben
  43.           általában csak néhány esetben tûnnek  ki -- és ez esetben  a
  44.           polcról levehetô  programok fejlesztôi  azzal védekezhetnek,
  45.           hogy  az  adott  esetben  egyedi  szoftvert  kellett   volna
  46.           alkalmazni.
  47.               Nem segít ezen a problémán a tesztelés sem. A Windows új
  48.           változatát    húszezer    önkéntes    tesztelte    különbözô
  49.           felhasználásokban.  Ez  igen hatásos  --  jegyezte meg  @Kifj.
  50.           @KSimonyi Károly,@N a Microsoft  vezetô tervezôje --, de  egyben
  51.           igen költséges  is, különösen  annak fényében,  hogy az  évi
  52.           92,8 milliárdot kitevô  amerikai szoftverforgalomból a  PC-s
  53.           alkalmazások alig 10 százalékkal részesülnek.
  54.               Kutatók  most  a  hibák  felfedezési  és   kiküszöbölési
  55.           módszereinek kifejlesztésén fáradoznak, mások a  felfedezett
  56.           hibákat  kívánják  orvosolni. Elsô  lépésként  -- hangzik  a
  57.           tanács -- lehetôleg  szabványos elemekbôl kell  megalkotni a
  58.           program vázát, prototípusát. Ez hozzásegíthet a  megrendelôk
  59.           és fejlesztôk közötti félreértések tisztázásához, a  feladat
  60.           konkrétabb megfogalmazásához. A prototípus megalkotása  után
  61.           kerülhet sor a feladat részletes kimunkálására.
  62.               Mások,  így a  Mitsubishi Electronics  kutatóintézetének
  63.           igazgatója, @KBelady László@N  szerint a prototípus  megalkotása
  64.           nem  segít,  mert  az ördög  mindig  a  részletekben van,  a
  65.           szoftverhibák  rendszerint   modulillesztési  zavarokra   és
  66.           elhanyagolásokra vezethetôk vissza,  így a programvázak  nem
  67.           segítik elô a programok kimunkálását.
  68.               Tulajdonképpen csak matematikai elemzéssel lehetne elôre
  69.           meghatározni a programok viselkedését, feltárni a  mélyebben
  70.           rejtôzô hibákat. Formális módszereket alkalmaztak például  a
  71.           brit   légiforgalmat    ellenôrzô   rendszer    programjának
  72.           tesztelésére, amelyben valamely elem meghibásodása esetén  a
  73.           redundáns elem veszi át annak funkcióját.
  74.               Automatikus   programtesztelésre   fejlesztette   ki  az
  75.           amerikai  Nemzeti   Szabványügyi  és   Technológiai  Intézet
  76.           megbízása   alapján   az    Incremental   Systems   cég    a
  77.           ""tisztaszoba" módszert.  Ez a  formális szoftverfejlesztést
  78.           igyekszik   ötvözni   a  helyességi   vizsgálatokkal   és  a
  79.           statisztikai ellenôrzéssel. A lapkagyártásnál -- ahonnan  az
  80.           eljárás a nevét kapta --  már az elsô példányoknak meg  kell
  81.           felelniük  az  elôírásoknak.  A  tisztaszoba  módszernél   a
  82.           szoftverfejlesztôk lépésrôl lépésre ellenôrzik munkájukat, a
  83.           lépések kimenetét statisztikailag vizsgálják, megállapítják,
  84.           hogy   milyen   gyakorisággal   következhet   be   hiba,   a
  85.           hibaanalízis   eredményeit   visszacsatolják,   és   ha    a
  86.           programokat jól ellenôrzött részprogramokból állítják össze,
  87.           akkor   gondosan   ellenôrzik   azok   illesztéseit,   végül
  88.           statisztikai   módszerekkel  értékelik   az  egész   program
  89.           megbízhatóságát. E  módszert alkalmazták  az Ericssonnál  az
  90.           elektronikus nagyközpontok szoftverének kifejlesztése során,
  91.           és ezzel sikerült az ezer kapcsolásonkénti eddigi  átlagosan
  92.           huszonöt tévesztés számát egyre mérsékelni.
  93.               A hatvanas  években számos  cég dicsekedett  azzal, hogy
  94.           meglelte a  programozás ellenôrzésének  legjobb módját.  Egy
  95.           évtizeddel késôbb a CASE-tôl  várták a megváltást, és  magas
  96.           szintû  programnyelvek, új  ellenôrzési technológiák  láttak
  97.           napvilágot,  de  ez   ideig  egyik  sem   bizonyult  valóban
  98.           eredményesnek.  A  szoftverfejlôdés  idôközben  lemaradt   a
  99.           hardverfejlesztés  és  - gyártás  termelékenysége  mögött. A
  100.           mind  nagyobb  sebességû  és  mind  nagyobb tárolókapacitású
  101.           hardver    nagy    kihívást    jelentett    és    jelent   a
  102.           szoftverfejlesztôk számára.  Ehhez hozzájárult  az is,  hogy
  103.           míg   a   hardvergyártás   termelékenysége   jól,   addig  a
  104.           szoftverfejlesztés termelékenysége alig mérhetô, nem is igen
  105.           mérik.  Az  általános mérnöki  gyakorlatot  számos kézikönyv
  106.           segíti, de nincs egyetlen általános programozási  kézikönyv,
  107.           hiszen  a   feladat  esetenként   más  és   más,  az  eltérô
  108.           megoldásokba különbözô módon csúszhatnak be hibák.
  109.               A  szoftverfejlesztés legnagyobb  kihívása a  szoftverek
  110.           hardverfüggôségének felszámolása,  a bármely  gépre, bármely
  111.           környezetre  könnyen adaptálható  programok vagy  legalábbis
  112.           programelemek megalkotása. A futurológusok látomása  szerint
  113.           elôbb-utóbb   a   világ   valamennyi   számítógépe  egyetlen
  114.           hálózatba lesz  kötve, és  a felhasználók  valamely központi
  115.           szoftvertárból egyedileg hívhatják  le a számukra  szükséges
  116.           programelemeket, amelyek  automatikusan illeszkednek  majd a
  117.           szabványosított  felületekhez.  A  lehívott  elemek  árát  a
  118.           rendszer  automatikusan  számlázza  majd  a felhasználóknak.
  119.           Lehet,  hogy   a  szoftverfejlesztôk   feladata  csupán   az
  120.           univerzálisan alkalmazható  szoftverek megalkotása  marad, a
  121.           gyakorlatban  alkalmazott  programok  összeállítása  a   nem
  122.           programozó felhasználó tevékenységi körébe megy át. Továbbra
  123.           is a specialisták feladata  marad azonban a nagy  rendszerek
  124.           megalkotása.
  125.  
  126.           @KReich György@N
  127.  
  128.  
  129.           @VMegdermedt repülôtér@N
  130.  
  131.               Példa  a  bonyolultabb   programok  hibáira  a   denveri
  132.           repülôtér csomagszállító  rendszerének esete.  Az új,  három
  133.           óriásgép  egyidejû  fogadására  alkalmas  denveri  repülôtér
  134.           tízszer  akkora,  mint  a  londoni  Heathrow. Csomagszállító
  135.           rendszere  harmincnégy  kilométernyi  szállítószalagból   és
  136.           négyezer elektronikus vezérlésû targoncából áll. A rendszert
  137.           kereken száz, hálózatba kötött számítógép, ötezer  érzékelô,
  138.           négyszáz rádió adó-vevô és ötvenhat vonalkódolvasó  vezérli,
  139.           irányítja. A 193 millió dollár költséggel felépült  rendszer
  140.           programjait  a  BAE  Automated  Systems  cég  kilenc hónapig
  141.           fejlesztette,   mégsem   sikerült   a   repülôtér  tervezett
  142.           megnyitási  idejére  elkészítenie, ezért  a  megnyitás elôbb
  143.           1993 decemberérôl 1994  márciusáig, majd júniusáig  húzódott
  144.           el, napi (!) 1,1 millió dollár veszteséget okozva. Végül  is
  145.           még sokat tévesztô szoftverrel nyitották meg a repülôteret.
  146.               Hasonló, ugyancsak a polgári repülésbôl származó eset  a
  147.           Sabre- é. 1970-ben fejlesztették ki az amerikai légiforgalmi
  148.           társaságok az évi  2 milliárd utas  helyfoglalását biztosító
  149.           Sabre   rendszert,  amely   kielégítôen  mûködött   1991-ig,
  150.           mindaddig,  amíg  össze  nem  kívánták  vonni  néhány   nagy
  151.           szállodalánc helyfoglalási rendszerével. Ez 1992-ben a hibás
  152.           helyfoglalások miatt perek sokaságába torkollott, 165 millió
  153.           dollár veszteséget okozva a szállodaláncnak.
  154.               Ezekbôl az  esetekbôl is  okulva az  Amerikai Szövetségi
  155.           Légügyi  Hatóság  1990-ben  már  másként  látott   munkához.
  156.           Elavult  légtér-  ellenôrzési  rendszerét  korszerûbbel,  az
  157.           Advanced  Automation  Systemmel (AAS)  kívánta  kiváltani. A
  158.           több  mint  1  millió  programsorra  tervezett  új  rendszer
  159.           kifejlesztésével az IBM-et bízta meg, 500  dollár/programsor
  160.           költséget irányozva elô, azaz mintegy ötször többet, mint az
  161.           átlagos ipari programok költségei. Végül a program soronként
  162.           700-900 dollárba, összesen  1,4 milliárdba került,  ám immár
  163.           hatodik  éve  számítógépek  százait  mûködteti  megfelelôen,
  164.           folyamatos  üzemben  figyelve  a  légteret  és  jelezve   az
  165.           esetleges váratlan eseményeket. Öt  év azonban e téren  nagy
  166.           idô. Mostanában vizsgálták felül a rendszert, és  határoznak
  167.           arról,  hogy   azt  a   növekvô  kívánalmaknak   megfelelôen
  168.           továbbfejlesztik vagy újat készítenek.
  169.               Katonai  kudarcról  lévén  szó,  nem  tudjuk   pontosan,
  170.           mennyit  veszített  az  amerikai  Védelmi  Minisztérium  egy
  171.           tavaly felbocsátott  katonai mûhold  programhibáján. A  múlt
  172.           tavasszal   fellôtt   Clementine   mûhold   fô   feladata  a
  173.           rakétaelhárító    rendszerekben    alkalmazandó     szoftver
  174.           kipróbálása  volt.  A kísérlet  kudarccal  zárult: a  mûhold
  175.           ahelyett, hogy tüzet nyitott  volna a céltárgyra, 11  percen
  176.           át csak követte azt,  végül pedig az üzemanyag  kimerültével
  177.           nem találkozott a Geographos aszteroidával sem.
  178.  
  179.  
  180.           @VSzáguldás a síneken@N
  181.  
  182.               Formális módszerekkel  ellenôrizte és  tökéletesítette a
  183.           francia  GEC-Alsthome  a  350  millió  dollár  ráfordítással
  184.           kifejlesztett,  a francia  vasutak hatezer  villanymozdonyát
  185.           vezérlô, sebességét szabályozó szoftverét. Növelhetô volt  a
  186.           vonatok  sebessége,  csökkenthetô  a  követési  távolság, és
  187.           ezzel fokozható volt a meglévô sínpárok kihasználtsága.  ìgy
  188.           feleslegessé vált új sínpárok dollármilliárdokat  felemésztô
  189.           lefektetése.  A  szoftvert   formálisan  és  a   lehetôségek
  190.           mértékéig matematikailag is ellenôrizték, majd  funkcionális
  191.           teszteket hajtottak végre.